A/B тестирование

Наша задача — провести оценку результатов A/B-теста.

В нашем распоряжении есть датасет с действиями пользователей, техническое задание и несколько вспомогательных датасетов.

Чтобы оценить корректность проведения теста, проверем:

Техническое задание

Входные данный

Ход исследования

  1. Обзор данных
    • Проведем загрузку и обзор предоставленных данных
  2. Предобработка данных
    • Проверка на дубликаты
    • Проверка на пропуски
    • Проверка заголовков на нарушения стиля
    • Проверка на другие не соответствия
    • Проверка на соответсвие техническому заданию
  3. Исследовательский анализ данные
    • количество событий на пользователя одинаково распределены в выборках?
    • как число событий в выборках распределено по дням?
    • как меняется конверсия в воронке в выборках на разных этапах?
  4. Функции для А/В анализа
    • функции для проведения и отображения анализа.
  5. Анализ A/B-теста
    • проверка гипотез
  6. Дополнительный анализ
    • посмотреть выручку в группах.
    • средний чек в группах
    • коффициент удержания в группах
  7. Выводы

Обзор данных

Мы проведем загрузку и обзор предоставленных данных

Импорт библиотек и загрузка данных

pandas - для загрузки и обработки данных мы воспльзуемся библеотекой .

numpy - библиотека высокоуровневых математических функций

scipy - библиотека математического и числового анализов

datetime - библиотека для работой с датой

re - модуль для регулярных выражений

seaborn - библиотека для создания статистических графиков

matplotlib.pyplot - библиотека для работы с графиками

plotly - библиотека визуализации данных (для воронкообразных диаграмм)

Загрузим файл из папки /datasets и сохраним в переменную

Загрузим файлы для проекта:

Данные загрузились корректно переходи к предобработке.

Предобработка данных

ссылка в содержание

на предварительном просмотре выявелись следущие замечания:

посмотрим на пустые ячейки подробнее,

какие события с не пустыми значениями:

purchase запонеными данными в колонке 'details', посмотрим что с пустыми значениями:

Понятно что колонка details это только стоимость покупки, при других событиях она пустая, будем иметь это ввиду.

напишем функцию для приведения колонок с датой к соответствующему типу:

применим к колонкам с датой:

хорошо, посмотри на аномалии кол-ва событий на одного пользователя:

Есть выбросы начиная примерно с 20 событий.

Посчитаем 95-й и 99-й перцентили количества событий на пользователя и выберем границу для определения аномальных пользователей.

20 событий на человека включают 99% пользователей.

Убирем аномальных пользователей.:

Остается 428 101 события из 440 317

Проверка на соответсвие техническому заданию

напишем небельшую функцию для вывода временного среза(минимальную и максимальную дату):

проверим срез времени на соответсвие ТЗ:

проверка на временой срез

в ТЗ указанно: дата запуска: 2020-12-07, дата остановки набора новых пользователей: 2020-12-21, дата остановки: 2021-01-04

таблица "Действия новых пользователей" дата запуска соответствует ТЗ, а вот дата остановки на 5 дней короче чем в ТЗ (2021-01-04 - 2020-12-30)

Данные по маркетинговым событиям ближайшая 25 декабря у нас набор закончился 21 декабря, позже на всякий случай посмотрим на пересечения мероприятий и нашего отрезка подробнее.

по ТЗ дата остановки 21 декабря все соответствует ТЗ, но нужно объеденить базы чтобы проверить что при объеденении часять данных отфильтруется по наличию данных пользователей в обеих базах:

хорошо временной срез соответствует техническому заданию.

поверка на пересечения

Посмотрим на проводимые тесты в нашей базе и кол-во пользователей:

при предварительном просмотре наш тест recommender_system_test в соответсвии с ТЗ набрал свыше 6000 (6701),

посмотрим как пользователи распределяется по группам в тестах.

в нашем тесте recommender_system_test видем не равномерное распределение, а вот второй тест распределился почти равномерно.

расчитаем как распределился наш тест в процентном соотношении:

Видим что в группе на ~7% больше чем в группе В, существенное различие в ~474 пользователя,

предварительно не понятно почему распределение прошло не равномерно нужно посмотреть дополнительные параметры пользователя, тип устройства и регион.

возможно есть где-то провал что в каком то регионе и/или устройстве было четкий перекос в одну из групп. Тогда можно сказать что убрав его мы сможем "выровнять" группы а организаторам теста указать на место где распределение пошло не по плану.

расмотрим в регионах прошло распределение:

распределение пользователей по регионам и устройствам:

Наблюдаем что новые пользователи для нашего теста преимущественно из Европы 95%.

Видим что распределение:

Это с учетом того что в Европе 95 % всех новых пользователей.

Распределение на устройства:

Во всех типах перекос в сторону группы А, и так же нет пустых чтобы подтвердить нашу теорию.

К сожаление точно установить где идет сбой не удалось,

Проверим как распределены данные в другом тесте:

В этом тесте разделение почти идеальное 51 / 49 %.

соберем всех user_id в свою группу и провери их пересечение:

пересечение тестов:

Видим что внутри тестов пересечений нет, а вот между собой они все пересекаются то есть пересекаются и контрольные группы и тестируемые.

соберем пересечения и дополним в нашу таблицу:

Видим что пересечение распределилось равномерно относительно деления нашего теста. 57 / 43 %

при этом видим что пересечение котрольноль группа А и контрольной группы

возьмем это к сведению, продолжим проверять все пунты ТЗ

выберем данные по нашим условиям:

аудитория EU увеличилась на ожидаемые 15%

объеденим данные для нашего исследования:

событий осталось всего 24 186.

пользователей всего 3 675 , что гораздо меньше 6 000 по ТЗ.

видимо у нас много не активных пользователей (пользователь зарегистрировался, а затем не совершил не одного действия или были проблемы со входом), надо взять на заметку, и сообщить разработчика что-то пошло не так.

добавим их к таблице аудитории:

после всех фильтраций осталось всего 8,2% новых пользователей из Европы.

так же подготовим данные для контрольного сравнения без пользователей участвовавших в тесте:

событий осталось всего 405 896.

пользователей всего 55 027

посмотрим на количество событий:

Вот как распределены данные по событиям:

Напишем функцию для формировании в группах и отображении воронки:

функция для отображения дней с добовление понедельников для удобства восприятия.

Создадим список нашей воронки:

применим нашу функцию для нашей тестируемой группы:

Вот как распределены данные по событиям:

от входа до покупки дошло 31% пользователей

Отдельно в группе В

Вот как распределены данные по событиям в группе А :

от входа до покупки дошло 32% пользователей

Отдельно в гуппе В

Вот как распределены данные по событиям в группе В :

от входа до покупки дошло 28% пользователей

Дополнительно посорим воронку пользователей не участвовавших в тесте:

Вот как распределены данные пользователей не участвовавших в тесте:

от входа до покупки дошло 34% пользователей

итог:

группа В на 4% хуже группы А в прохождения до покупки. Группа А ниже контрольной группы на 2%.

Силных отличий на этапах самой воронки между групп практически нет.

можно увидеть что не все этапы воронки обязательны, например product_cart тоесть можно совершить покупку не заходя обязатеьно в корзину.

Чуть подробнее посмотри на не дошедших до вхождения по своим аккаунтом пользователе (зарегистрированных, но не активных):

добавим эти данные в общею агрегированную таблицу по тесту:

В тесте 45% не активных пользователей, при это не равномерно расределеных по базе.

Видим что есть проблема в группе А у 36% пользователей со входом в приложение, в группе В все гораздо хуже, мало того что они набрали изначально на 7% меньше пользователей, так еще не активных 64% 2/3 пользователей не заходили в приложение.

посмотрим их данные поближе:

нет четкого понимания чтобы можно было сказать на каком то проблемном девайсе или регионе. но проблема явно присутсвует что при расределение групп что со входом после регистрации.

посотрим есть ли токая проблема с пользователями из второго теста.

Да тоже есть не активные пользователи, но их всего 6%.

Нужно разбараться разработчикам теста что пошло не так во время набора данных для этого теста.

проверка влияния маркетинговых мероприятий

видим что не одно мероприятие не пересеклось с исследуемым периодом.(с 7 по 21 декабря 2020)

в связи с условиями задачи что "за 14 дней с момента регистрации пользователи покажут улучшение каждой метрики не менее, чем на 10%" уберем лишний лайфтайм у пользователей.

хорошо идем дальше.

ссылка в содержание

Исследовательский анализ данные

Как количество событий распределены на пользователя в выборках

У группы А в среднем почти 7 событий, и В почти 6 события напользователя. Посмотрим медиану:

по медиване у А 6 у В 5 на каждого пользователя.

построим график распределения событий:

действительно в среднем 6 событий.

проверим статистический тестом, критерий Шапиро-Уилка:

Данные распределены не нормально. посчитаем 95-й и 99-й перцентили кол-ва событий у пользователей и выявим аномальных пользователей.

будем считать аномальных совершивших больше 14 событий.

Кол-во событий по дням:

видим что с 7 по 10 декабря были примерно одинаковы (270 событий), затем к 13 декабря в группе В события ниже 250 событий.

кол-во событий резко растет у группы А 14 декабря свыше тысячи событий, и дальнейший рост до пика 21 декабря 2000 событий.

затем падение к 28 декабря до 500 событий. группа В тоже имеет небольшие калебания повторяищие группу А только гораздо в мешьшем диапозоне (100-450 событий) для общей картины нужно посмотреть рост пользователей в группах.

в точности аналогично кол-ву событий, тоесть ко-во событий зависят только от кол-во пользователей а средее кол-во событий в группах примерно одинаковое, посмотрим на кол-во событий в группах по дням недели:

В начале недели разрыв почти 4 кратный(3900 / 1200), но к среде разрыв уменьшается (2500 / 1000) в основном за счет сокращения в группе А, далее группа А стабильна а В еще уменьшается и к концу недели разрыв в 4 раза (2500 / 600) в пользу группы А.

Посотрим как по дням разделяются конкретные события в группах:

тут нет явных акцентов все в принцепе повторяет общую динамику.

посмотрим динамику пользователей по регионам:

видим что скачек происходит от резкого раста пользователей Европы с 150 до 400 14 декабря и до 750 21 декабря и дальше идет на спад. Возможное влияние праздников.

посмотрим динамику по устройствам:

видим анологичную картину по росту пользователей но рспределенно все в соотношении нет выбивающегося устройства как при делении на регионы.

для сравнения посотрим на тот же промежуток но у остальных пользователей не принимавших участия в тесте:

тот же график с разрезо по типам события:

на этих данных похожая форма с группой А из нашего теста, пики 14 и 21 по понедельникам. возможно этот всплеск относится к подготовке к рождеству 25 декабря по григорианскому календарю, все покупают подарки. Так что данные даже без пересечениями с маркетинговыми акциями подвергается сезонному искажению.

Так же обротим внимание на резкий скачек кол-во событий в группе А 14 декабря,скорее всего связан с резким увеличением кол-во пользователей в этой группе.

Перед тестированием нужно убедится:

  1. на результаты не влияют аномалии и выбросы в генеральной совокупности
  2. инструмент «деления» трафика работает безошибочно;
  3. данные отправляются в системы аналитики корректно.

1) мы отбросили анамальных пользователей 2) иструмент работает не совсем верно поделив аудиторию теста на 57 / 43% (до фильтрации с активными пользователями) 3) данные отправляются корректно(пропусков и дубликатов мы не обнаружили)

по части критериев мы не можем переходить к анализу А/В теста так как он не соответствует части критериев.

берем во внимание все выше перечисленное и переходим к тесту.

ссылка в содержание

Функции для А/В анализа

функция для статистической проверки гипотез методом z-тест для пропорций :

функция формирования пользовательских сессий:

ссылка в содержание

Анализ А/В-теста

подготовим данные:

Сформулируем гипотезы:

очевидный вывод, предварительно мы предпологали такой исход.

Посмотрим распределение в группах по событиям:

для удобства напишем функцию для перебора ячеек:

выставим границу альфа в 5%, но чтобы снизить групповую вероятность ошибки первого рода и скорректировать требуемые уровни значимости установим уровень равный количеству тестируемых групп применим метод Холма и Шидака

Для проверки используем нашу функцию z-тест для пропорций, сформулируем гипотезы:

Cтатистически значимые отличия между группами есть в product_page, а вот в двух событиях product_cart,purchase нет оснований чтобы считать доли разными.

ссылка в содержание

Дополнительный анализ:

так как мы имеем данные по выручке можем провести дополнительный анализ, подготовим данные по заказам:

данные по ссумме заказов и средней суммы на одного пользователя:

Наблюдаем:

В группе В все показатели ниже группы А.

подготовим данные по посещениям:

Построим график кумулятивной выручки по группам и сделаем выводы и предположения:

Группа А стабильно выше В, присутствует плавное увеличение выручки с 13 числа.

Возможно все тоже влияние увеличения кол-во пользователей в группе.(так как в группе А в 3 раза больше пользователей)

Построим график кумулятивного среднего чека по группам

При всех лучших показателях группы А, здесь наблюдаем плавный рост с 12 декабря группы В для среднего чека

от 14 до 24 едениц к 17 декабря. группа А показывает средений чек в диапозоне 25-27, идет плавное снижение с 8 декабря(27) до 28 декабря (25).

Построим график относительного изменения кумулятивного среднего чека группы B к группе A

На графике видим резкие скачки между сегментами, возможно это влияние аномальных заказов.

Построим график кумулятивного среднего количества заказов по группам

Построим график относительного изменения кумулятивного среднего количества заказов группы B к группе A

видим что с начала наблюдаемого периода лидирует группа А на 15% , с 8 числа все меняется и сначала выравнивается разница в 0 затем с 13 начинается плавный рост группы В до 12%.

Построим точечный график количества заказов по пользователям

Видем что большинство заказов не превышают 5 заказов на пользователя.

Посчитаем 95-й и 99-й перцентили количества заказов на пользователя и выберем границу для определения аномальных пользователей.

Построим точечный график стоимостей заказов.

На графике видем очень аномальный заказов нет

Видим что большинство заказов не превышают 500.

Посчитаем 95-й и 99-й перцентили стоимости заказов и выберем границу для определения аномальных пользователей.

Посчитаем статистическую значимость различий в среднем чеке заказа между группами

Сформулируем гипотезы:

не большая относительная разница при отсутствии статистической значимости говорит о влиянии выбросов.

Посмотрим на удержание в группах:

подготовим данные:

применим нашу функцию для определения сеансов:

вызовем нашу функцию для создания таблицы профелей:

Вызовим нашу функцию для определения из каких регионов пользователи приходят в приложение и на какуй регион приходится больше всего платящих пользователей.

Так же вызовим функцию для определения какими устройствами пользуются клиенты и какие устройства предпочитают платящие пользователи.

что происходит при делении на тестируемые группы:

посмотри как что с удержанием:

Удивительно но динамика удержания и у платящих и не плотящий в обеих группах происходит схожим образом, группа А стабильно лучше группы В.

по динамике на 14 день:

Выводы

  1. Обзор данных
  2. Предобработка данных
  3. Проверка на соответсвие техническому заданию
  4. Исследовательский анализ данные
  5. Анализ A/B-теста
  6. Результаты A/B-тестирования

До выводов нужно выделить проблемные места исследования:

По техническому заданию:

детали:

рекомендации:

по результатам теста: нужно остановить тест, признать его не состоявшимся слишком много недостатков после предобработки данных.